DKIM Selector
DKIM Selector settings
Selector
Selector
To support multiple concurrent public keys per signing domain,
the key namespace is subdivided using "selectors".
For example, selectors might indicate the names of office locations (e.g., "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date (e.g., "january2005", "february2005", etc.), or even the individual user.
Selectors are needed to support some important use cases. For example:
Domains that want to delegate signing capability for a specific address for a given duration to a partner, such as an advertising provider or other outsourced function.
Domains that want to allow frequent travelers to send messages locally without the need to connect with a particular MSA.
"Affinity" domains (e.g., college alumni associations) that provide forwarding of incoming mail, but that do not operate a mail submission agent for outgoing mail.
Periods are allowed in selectors and are component separators.
When keys are retrieved from the DNS, periods in selectors define DNS label boundaries in a manner similar to the conventional use in domain names.
Selector components might be used to combine dates with locations, for example, "march2005.reykjavik".
In a DNS implementation, this can be used to allow delegation of a portion of the selector namespace.
general
Granularity
This is used to allow you to use specific selectors for specific addresses. For example if you specify offers* then all email with the From field matching offers* (e.g. offers-now@mydomain.com) will
be signed with this selector, and verification will take place as expected by the recipient.
Hexamail ensures the Local-part of the "i=" tag of the DKIM-Signature header field (or its default value of the empty string if "i=" is not specified) will match this granularity settings.
A single, optional "*" character matching a sequence of zero or more arbitrary characters ("wildcarding").
An email with a signing address that does not match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can legitimately use this selector, for example,
when delegating a key to a third party that should only be used for special purposes.
Wildcarding allows matching for addresses such as "user+*" or "*-offer". An empty granularity value never matches any addresses, you should have * to mean any address at your domain.
*
Subdomains
This setting controls whether subdomains are allowed in the identity tag of email signatures.
If subdomains are not allowed, the following applies:
Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag.
That is, the "i=" domain MUST NOT be a subdomain of "d=".
Prohibiting subdomaining is RECOMMENDED unless subdomaining is required.
Off
Advanced
Test
If you are testing then you can enable this test setting to be sure that remote recipient servers will ignore signatures signed using this selector
. If enabled verifiers MUST NOT treat messages from signers in testing mode differently from unsigned email,
even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the signer.
Off